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1.  Scope. 

1.1.  Identification. 

This  document  describes  the  software  design  for  the  Vehicle  Integrated 
Defense  System  (VIDS)  simulation  and  its  inclusion  into  the  existing  Ml 
Tai\k  Simulator  software.  This  software  design  satisfies  requirements 
contained  in  the  Requirements  traceability  tables  (Action  7). 

1.2.  System  overview. 

The  VIDS-equipped  Ml  Tank  Simulator  exists  to  support  a  series  of 
survivability  experiments.  The  nature  of  the  experiments  requires  that  the 
VIDS  simulation  be  parameter  driven.  The  VIDS  parameters  not  only  define 
available  sensors  and  countermeasures,  but  also  define  their  respective 
sensitivities  and  respoixse  times.  For  the  present,  eight  sensors  and  nine 
coimtermeasures  are  simulated: 

a.  Laser  Warning  Receiver  (LWR). 

b.  Missile  Warning  System  (MWS). 

c.  Future  Armored  System  Radar  (FASR). 

d.  Seismic  Mine  Sensor. 

e.  Non-Imaging  System  (NIS). 

f.  Tank  Radar  Warning  Receiver  (TRWR). 

g.  Miizzle  Flash  Detector  (MFD). 

h.  Nuclear  Chemical  Sensor  (NCS). 

Countermeasures 

a.  Multi-Salvo  Smoke  Grenade  La vmcher /Rapid 
Obscuration  System  (ROS). 

b.  Missile  Countermeasure  Device  (MCD). 

c.  Combat  Protection  System  (CPS). 

d.  Laser  Countermeasure  Device  (LCMD). 

e.  Vehicle  Magnetic  Signature  Duplication  (VEMASID). 

f.  Nuclear  Biological  Chemical  Overpressure  (NBCOP). 

g.  Advanced  Threat  Radar  Jammer  (ATRJ). 

h.  Threat  Countermeasure  System  (TCS). 

i.  Chaff /Flares. 

In  general,  the  VIDS  system  responds  to  perceived  threats  in  the  following 
ways: 

a.  by  displaying  visual  icons  on  the  Commander’s  Controls  Display  Panel 
(CCDP). 
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b.  by  generating  alert  tones  or  playing  alert  messages  which  can  be  heard 
on  the  tank  crew  intercom. 

c.  by  examining  user-selected  countermeasure  activation  modes. 

d.  by  seizing  control  of  the  turret. 

e.  by  activating  a  selected  countermeasure  for  each  perceived  threat. 

Because  VIDS  can  seize  control  of  the  turret,  automatic  turret  rotation  for 
counterfire  is  supported.  Furthermore,  VIDS  supports  automatic  turret 
slewing  for  visual  detection  of  threats. 

13.  Document  overview. 

This  document  identifies  and  describes  new  software  CSCs  and  CSUs,  as  well 
as  changes  to  and  reuse  of  existing  Ml  Simulator  CSCs  and  CSUs.  Diagrams 
and  narratives  are  used  to  explain  how  the  new  VIDS  simulation  executes 
within  the  framework  of  the  existing  Ml  Simulator. 

2.  Referenced  documents. 

2.1.  Government  documents. 

SPECmCATIONS: 

1.  PM-Survivability:  VIDS  Armored  Vehicle  Survivability 

Equipment  (AVSE)  BDS-D  Functional  Specifications,  29  May  1992. 

23.  Non-Government  documents. 

1.  Loral:  Battlefield  Distributed  Simulation-Development  (BDS-D) 
Vehicle  Integrated  Defense  System  (VIDS)  Feasibility  Analysis 
Report,  14  October  1992. 

2.  BBN:  The  SIMNET  Neh^'ork  and  Protocols,  Report  7627,  June  1991. 

3.  Preliminary  design. 

3.1.  CSCI  overview. 

The  VlDS-equipped  Ml  Tank  Simulator  (hereafter  referred  to  as  the  VIDS- 
equipped  taiik)  exists  as  one  of  many  entities  participating  within  a  simulated 
battle.  Each  entity  communicates  with  other  entities  by  sending  and  receiving 
Protocol  Data  Units  (PDUs)  on  an  Ethernet©  network.  The  external 
interfaces  for  the  VIDS-equipped  tank  are  illustrated  in  Figure  1. 


_  0  _ 
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Figtire  1.  VIDS  External  Interfaces 

Incoming  PDUs  describe  the  activity  in  one  or  more  simulated  battlefields. 
Because  the  number  of  incoming  PDUs  can  be  quite  large,  a  series  of  high- 
level  filters  are  applied  to  retain  only  those  PDUs  which  are  applicable  to  a 
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specific  entity.  Applicable  PDUs  are  then  filtered  based  upon  entity-specific 
parameters  such  as  exercise  number,  distance  and  available  sensors. 
Remaining  PDUs  are  then  classified  and  used  to  influence  either  the  entity 
behavior  or  what  the  entity  can  detect. 

Outgoing  PDUs  describe  the  visual  appearance  or  behavior  of  the  VIDS- 
equipped  tank.  Typically,  these  define  the  current  tank  hull  position  and 
orientation,  the  turret  orientation,  the  presence  of  smoke  clouds,  chaff/flares 
or  the  existence  of  electro-optical  energy.  For  experimental  purposes,  a  subset 
of  the  outgoing  PDUs  contain  instrumentation  information  which  can  be 
used  by  analysts  to  better  understand  VIDS  behavior  and  the  use  of  the 
soldier-machine  interface. 

3.1.1.  CSQ  architecture. 

The  VIDS  capability  is  partitioned  between  two  host  computers.  One  host  is 
the  current  Ml  tank  GT  hardware;  the  other  host  is  a  PC  with  an  Biographies 
touchscreen  mounted  in  front  of  a  13  inch  color  video  monitor.  The  software 
executing  on  the  PC  supports  the  Soldier  Machine  Interface  (SMI),  hereafter 
referred  to  the  as  the  CCDP.  This  includes  all  the  VIDS  buttons,  setup 
windows  and  the  display  windows.  The  software  executing  on  the  GT 
simulates  the  behavior  of  the  sensors,  coimtermeasures  and  threat  resolution 
module  (TRM). 

The  VIDS-PC  and  VIDS-GT  communicate  with  one  another  just  like  other 
entities  participating  within  a  simulated  battle  exercise.  Because  there  may  be 
multiple  VIDS-equipped  tanks  within  the  same  exercise,  the  VIDS-PC  and 
VIDS^T  are  paired  so  orUy  appropriate  network  messages  are  recognized  and 
processed.  In  other  words,  the  VIDS-PC  knows  the  unique  identifier 
(VehiclelD)  of  its  corresponding  VIDS-GT,  and  the  VIDS-GT  knows  the 
unique  VehiclelD  of  its  corresponding  VIDS-PC. 

3.1.2.  System  states  and  modes. 

The  VIDS-GT  CSCI  operates  in  one  of  six  predefined  states.  These  states  are; 

a.  Startup. 

b.  Idle. 

c.  Initialize. 

d.  Simiolate. 

e.  Stop. 

f.  Exit. 

Within  the  VIDS  context,  only  the  Startup,  Initialize  and  Simulate  states  are 
significant. 
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During  the  Startup  State,  specific  hardware  devices  are  initialized  and 
parameter  files  are  read.  It  is  during  this  state  that  the  \1DS  parameter  file 
(VIDS.D)  is  read  to  establish  the  types  and  behaviors  of  available  sensors  and 
countermeasures.  This  file  also  contains  a  recommended  list  of 
countermeasures  for  each  type  of  threat. 

Once  all  the  tank  parameter  files  have  been  read,  a  communication  link  to 
the  Simulation  Network  (SIMNET)  is  established.  Having  successfully 
completed  these  tasks,  a  traxisition  is  made  to  the  Idle  State. 

During  the  Idle  State,  the  Ml  Tank  Simulator  waits  to  receive  an  activation 
request  from  SIMNET.  (The  activation  request  is  generated  by  a  user  of  the 
MCC-SCC  console.)  When  an  Activation  Request  PDU  is  received,  a 
traixsition  is  made  to  the  Iiutialize  State. 

During  the  Initialize  State,  additional  hardware  and  internal  software 
initialization  is  performed.  For  VIDS,  sensor  detection  and  identification 
probability  tables  are  built;  and  default  alert,  safety,  countermeasure  coverage 
and  turret  scaiuung  sector  settings  are  sent  to  the  VIDS-PC.  Additionally,  the 
list  of  available  countermeasures  and  the  inventories  of  the  expendable 
countermeasures  are  sent  to  the  VIDS-PC.  Having  successfully  completed 
this  initialization,  a  transition  is  made  to  the  Simulate  State. 

The  Simulate  State  represents  the  main  processing  loop  for  the  VIDS-GT. 
PDUs  sent  by  the  VIDS-PC  are  read  and  used  to  alter  the  behavior  of  VIDS. 
Electro-optical  PDUs  from  other  entities  are  read  and  used  to  determine  if  a 
threat  is  present.  When  a  threat  is  detected,  PDUs  are  sent  to  the  VIDS-PC  to 
provide  visual  and  audible  cues.  Furthermore,  detected  threats  are 
prioritized;  and  countermeasures  are  selected  and  activated.  The  Simulate 
State  continues  until: 

a.  An  impact  PDU  is  received  which  destroys  the  tarUc. 

b.  A  deactivation  PDU  is  received  which  forces  a  transition  to  the  Stop 
State. 

b.  A  reconstitute  PDU  is  received  which  forces  a  transition  to  the  Idle 
State. 

c.  An  exit  command  is  received  from  the  Ml  Console  keyboard  which 
forces  a  transition  to  the  Exit  State. 

During  the  Stop  State,  a  transition  is  made  to  the  Idle  State,  followed  by  a 
transition  to  the  Exit  State. 

For  the  VIDS-PC,  there  are  only  three  states:  Initialize,  Simulate  and 
Shutdown.  During  the  Initialize  State,  data  files  are  read  which  define  button 
positions,  content  and  behavior.  Furthermore,  the  VIDS-PC  waits  to  receive 
the  default  alert,  safety,  coimtermeasure  coverage  and  turret  scanning  sector 
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settings  from  the  VIDS-GT.  Once  these  settings  have  been  received,  a 
transition  is  made  to  the  Simulate  State. 

As  with  the  VIDS-GT,  the  Simulate  State  represents  the  main  processing  loop 
for  the  user  interface.  The  touchscreen  is  continually  monitored  to 
determine  if  a  button  has  been  depressed  or  released.  Specific  button  actions 
may  generate  brief  user  alert  messages  to  appear  on  the  display  panel. 
Changed  button  values  or  sector  coverage  widths  are  sent  back  to  the  VIDS- 
GT  to  influence  the  behavior  of  the  sensors  and  countermeasures.  The 
network  buffer  is  continually  polled  to  determine  if  PDUs  sent  by  the  VIDS- 
GT  require  updates  to  the  display  or  if  audible  alerts  must  be  activated  or 
terminated. 

Diuring  the  Shutdown  State,  dynamic  memory  is  released,  special  interrupt 
handling  is  suspended  and  control  is  released  to  the  normal  operating  system. 

3.13.  Memory  and  processing  time  allocation. 

At  the  present  time,  there  are  no  memory  budgets  more  restrictive  than  those 
imposed  by  the  respective  host  computers.  However,  the  VIDS-GT  functior\s 
which  execute  during  the  Simulate  State  must  execute  faster  than  1/15*^  of  a 
second.  This  is  due  to  the  fundamental  execution  cycle  on  the  GT.  In  fact,  the 
VIDS  software  execution  speed  must  take  only  a  relatively  small  percentage 
(20%  or  less)  of  the  66.67  inilliseconds  since  the  sum  total  of  all  simulated  Ml 
behavior  must  execute  within  this  time  frame. 

33.  CSO  Design  Description. 

Because  the  simulated  VIDS  system  is  partitioned  between  two  host 
computers,  the  description  of  the  VIDS  CSC  is  divided  into  two  parts-  the 
VIDS-GT  CSC  and  the  VIDS-PC  CSC.  Note  that  the  VIDS-PC  CSC  is  also 
referred  to  as  the  Soldier  Machine  Interface  (SMI)  and  the  Commander's 
Controls  Display  Panel  (CCDP). 

33.1.  VIDS-GT  CSC 

The  VIDS-GT  CSC  handles  the  job  of  simulating  the  behaviors  of  available 
sensors  and  countermeasures.  Parameters  sent  by  the  VIDS-PC  CSC  are  used 
to  constrain  the  behavior  of  the  VIDS-GT  CSC.  Parameters  sent  by  the  VIDS- 
GT  CSC  to  the  VIDS-PC  CSC  are  used  to  inform  the  tank  commander  what  is 
known  about  any  hostile  threats.  Specific  design  features  include: 

a.  The  VIDS-GT  CSC  satisfies  all  requirements  presently  allocated  to  the 
GT.  Refer  to  the  table  in  Section  7  to  locate  which  specific 
requirements  are  satisfied. 
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b.  The  VIDS-GT  CSC  is  subdivided  into  three  lower-level  CSCs: 
VIDS.File.Read,  VIDS^Init  and  VIDS.Simul. 

c.  Each  of  the  three  lower-level  CSCs  are  executed  in  sequential  order. 
VIDS_FiIe_Read  and  VIDS_Init  are  executed  only  once; 
VIDS_Simul  is  executed  15  times  a  second  as  part  of  the  Ml  code 
which  executes  in  the  Simulate  State. 

3^1.1.  VIDS^File.Read  CSC 

The  VIDS_File_Read  CSC  handles  the  job  of  reading  a  specific  text  file 
(VIDS.D)  defining  the  available  sensors  and  countermeasures  and  the 
corresponding  behaviors.  Specific  design  features  include: 

a.  This  CSC  satisfies  the  requirements  for  a  parameter-driven  set  of 
sensor  and  countermeasure  behaviors.  Refer  to  the  table  in  Section  7 
to  locate  which  specific  requirements  are  satisfied. 

b.  This  CSC  sequentially  reads  a  specific  text  file.  Each  line  is  either  a 
comment  or  a  keyword-value(s).  Comment  lines  are  skipped. 
Keywords  are  used  to  discriminate  which  values  are  being  read,  what 
format  must  be  used,  and  where  they  must  be  stored. 

c.  The  text  file  containing  the  sensor  and  countermeasure  behaviors  is 
read  only  once. 

VIDS  Jnit  CSC 

The  VIDS_Init  CSC  handles  the  job  of  preallocating  dynamic  memory, 
initializing  queues,  initializing  countermeasure  rotation  CSCs  and  sending 
default  parameters  to  the  VIDS-PC.  Specific  design  features  include: 

a.  This  CSC  does  not  satisfy  any  system-level  requirements. 

b.  This  CSC  handles  the  job  of  preallocating  and  initializing  the 
dynamic  memory  to  be  used  during  the  simulation  of  the  VIDS 
behavior.  Fiarthermore,  it  performs  a  critical  initialization  step  by 
sending  the  VIDS-PC  a  set  of  default  alert,  safety,  countermeasure 
coverage,  turret  scanning  sector  settings  the  list  of  available 
countermeasures  and  the  inventories  of  the  expendable 
countermeasures. 

c.  This  CSC  satisfies  the  design  requirements  for  preallocating  and 
initializing  dynamic  memory  and  providing  default  parameters  to 
the  VIDS-PC. 
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d.  This  CSC  satisfies  the  design  requirements  for  initializing  internal 
tables  used  by  the  CSCs  which  handle  countermeasure  rotations. 

3^13.  VIDS_Simul  CSC 

The  VIDS_Siniul  CSC  handles  the  job  of  managing  the  majority  of  other 
lower-level  CSCs.  It  is  these  lower-level  CSCs  which  model  the  behavior  of 
the  available  sensors,  countermeasures  and  TRM.  Specific  design  features 
include: 


a.  This  CSC  and  its  lower-level  CSCs  satisfy  a  majority  of  the  system- 
level  requirements  allocated  to  the  GT.  Refer  to  the  table  in  Section  7 
to  locate  which  specific  requirements  are  satisfied. 

b.  This  CSC  handles  the  job  of  sequentially  executing  lower-level  CSCs. 
These  CSCs  perform  ^e  following  functions: 

1.  Getting  updates  from  the  CCDP. 

2.  Reacting  to  main  and  turret  power  state  changes. 

3.  Determining  if  there  are  new  threats. 

4.  Qassifying  threats  based  upon  what  is  cxorrently  known. 

5.  Prioritizing  the  current  threats. 

6.  Selecting  countermeasures. 

7.  Activating  countermeasures. 

8.  Sending  updated  threat  status  to  the  VIDS-PC. 

9.  Sending  coimtermeasure  activation  PDUs  to  other  entities 
participating  within  the  same  simulated  battle  exercise. 

10.  Managing  the  rotation  of  the  independent  slewing 
countermeasures. 

c.  This  CSC  satisfies  the  design  requirement  for  monitoring  the  main 
tai\k  and  turret  power  states. 

33.1.4.  VIDS.Shutdown  CSC 

The  VIDS_Shutdown  CSC  handles  the  job  of  terminating  the  VIDS 
simulation  and  sending  the  firul  power  states  to  the  VIDS-PC.  Specific  design 
features  include: 

a.  This  CSC  does  not  satisfy  any  system-level  requirements. 

b.  This  CSC  satisfies  the  design  requirements  of  formally  deallocating 
the  dynamic  memory  used  during  the  simulation  of  the  VIDS 
behavior.  Furthermore,  it  prints  a  summary  of  the  memory  usage  to 
the  main  cor\sole. 


3.2.2.  PC-Resident  VIDS  CSC 
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The  VII>S-PC  CSC  handles  the  job  of  simulating  the  CCDP.  This  includes  a 
set  of  multi-function  buttons  as  well  as  the  ability  to  activate  audible  alarms 
and  display  threat  information.  The  display  screen  is  used  to  portray  the  type 
and  position  of  threats  relative  to  the  tank.  Specific  design  features  include: 

a.  The  VIDS-PC  CSC  satisfies  all  requirements  presently  allocated  to  the 
SMI.  Refer  to  the  table  in  Section  7  to  locate  which  specific 
requirements  are  satisfied. 

b.  The  VIDS-PC  CSC  is  subdivided  into  3  lower-level  CSCs:  SMI_Iiut, 
SMI_Simul,  SMI_Shutdown. 

c.  Each  of  the  three  lower-level  CSCs  are  executed  in  sequential  order. 
SMI_Init  and  SMI_Shutdown  are  executed  only  once;  SMI_Siinul  is 
executed  endlessly  until  a  keyboard  Control-C  or  the  right  mouse 
button  is  depressed. 
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4.  Detailed  Design. 

The  detailed  design  is  divided  into  two  parts.  The  first  part  describes  the 
VIDS-GT  CSC  and  the  second  part  describes  the  VIDS-PC  CSC. 

4.1  VIDS-GT  CSC  Detailed  Design 


4.1.1.  VIDS_File_Read  CSC 

VIDS_File_Read  reads  a  text  file  (VIDS.D)  which  defines  the  list  of  available 
sensors  and  countermeasiires  and  the  corresponding  behaviors.  This  CSC  is 
executed  only  once  during  the  Startup  State  of  the  existing  Ml  code. 
Furthermore,  the  text  file  contains  automatic  turret  rotation  rates  for  each 
coimte'rmeasure,  counterfire  and  turret  scanning.  The  text  file  also  contains 
the  unique  identification  (VehiclelD)  of  the  PC  which  simulates  the  behavior 
of  the  corresponding  CCDP. 

Once  all  the  parameters  have  been  read,  they  are  stored  in  tables.  For  sensors, 
this  includes  coverage  angles,  range  limitation,  detection  probabilities  and 
reaction/delay  times.  For  countermeasures,  this  includes  the  coverage  angles, 
reaction/delay  times  and  in  some  cases  (ROS  and  Chaff/Flares)  launch 
distances.  For  the  Threat  Resolution  Module  (TRM),  this  includes  the 
recommended  countermeasures  and  priorities  for  each  threat  type. 

4.1.2.  VIDSJnitCSC 

VIDS_Init  preallocates  dynamic  memory  structures  which  are  used 
frequently  during  the  execution  of  the  VIDS_Siniul  CSC.  Preallocation  is 
done  here  purely  for  efficiency  because  VIDSJnit  is  invoked  diiring  a  non- 
critical  processing  state. 

VIDS_Init  also  sends  default  settings  and  expendable  countermeasure 
inventories  to  the  CCDP.  This  done  to  allow  alert,  safety,  countermeasure 
coverage  and  turret  scanning  sector  settings  to  be  graphically  portrayed  when 
the  CCDP  is  powered  on. 

Finally,  VIDS_Init  invokes  functions  which  initialize  the  independently 
slewing  countermeasure  rotation  tables.  During  this  initialization,  slewing 
coimtermeasure  devices  are  aligned  in  the  same  direction  as  the  main  gun. 

4.1.3.  VIDS.Simul  CSC 

VIDS_Sinaul  serves  as  the  primary  entry  point  for  simulation  of  the  sensors, 
TRM  and  covmtermeasures.  It  represents  the  root  of  a  functional  hierarchy 
which  is  executed  once  during  each  execution  cycle  of  the  existing.  Ml 
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simulation  software.  During  a  single  execution  cycle,  the  following  high- 
level  functions  are  executed: 

Get_CCDP_Updates(); 

React_to_Power_State_Changes(); 

Identify_Threats(); 

Manage_Countermeasures(); 

S€nd_Updates_to_CCDP(); 

Send_Updates_to_Network(); 

Need_To_Release_Turret(); 

CM_Rotation_Simul(); 

Poison_Siniul();  ^ 

Each  of  these  functions  represent  a  functional  sub-hierarchy  which  is 
described  in  the  following  sections. 

4.1.3.1.  Get_CCDP_Updates  CSU 

Get_CCDP_Updates  retrieves  the  current  CCDP  settings.  These  settings  are 
changed  by  user  interaction  with  the  touch  screen.  It  is  assumed  that  all  error 
checl^g  is  performed  by  the  VIDS-PC.  Consequently,  all  individual  values 
are  assumed  to  be  error-free  and  that  combinations  of  settings  are  valid. 

4.1.3.2.  React_to_Power_State_Changes  CSU 

React_to_Power_State_Changes  determines  if  the  VIDS-GT  system  should 
continue  to  respond  to  sensor  input  and  activate  countermeasures.  This  is 
done  by  checking  that  both  the  tank  Master_Power  and  Turret_Power  are  on. 
Only  when  they  are  both  on  can  VIDS  be  on. 

When  VIDS  is  off,  internal  data  structures  used  to  maintain  knowledge  of 
threats  and  active  countermeasures  are  discarded.  Later  on  in 
Send_Updates_to_CCDP,  the  VIDS_Power_State  is  sent  to  the  CCDP  so  that  a 
similar  cleanup  can  occur  on  the  VIDS-PC. 

4.1.33.  Identify_Threats  CSC 

Identify_Threats  serves  as  the  primary  entry  point  of  sensor  simulation. 
Only  when  VIDS  is  on  is  a  test  is  made  to  determine  if  there  are  any  new 
threat  reports.  For  sensors  which  track  threat  positions  and  proximities  (NIS 
and  FASR),  periodic  queries  are  made  to  retrieve  current  threat  reports.  Each 
report  is  sent  to  Process_Detected_Threat()  to  determine  if  the  required 
sensor  is  available.  When  the  corresponding  sensor  is  available,  the  threat 
report  is  placed  into  a  queue  for  sensor-specific  processing. 

Since  a  threat  can  be  manually  deleted  at  any  time,  ManuaLThreat_Update 
in  invoked  to  determine  if  the  current  CCDP_Control_Settings  indicate  a 
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manual  threat  deletion.  When  a  deletion  is  indicated,  the  supplied  threat 
identification  is  used  to  search  and  delete  its  record  from  the  prioritized  threat 
list. 

Finally,  each  new  threat  report  is  processed  by  the  corresponding  sensor.  The 
required  sensor  is  sent  to  EO_Sensor_Simul.  EO_Sensor_Simul  is  a  generic 
function  which  is  invoked  to  model  the  behavior  of  a  specified  sensor. 

4.1.33.1.  EO_Sensor_Simul  CSC 

EO_Sensor_Sintul  serves  as  the  primary  entry  point  for  simulation  of  all 
sensors.  This  CSC  is  subdivided  into  three  functional  parts:  one  which 
simulates  reaction  delay,  one  which  handles  detection  probability,  and  one 
which  processes  new  threats  as  a  fimction  of  sensor-specific  coverage  limits. 
The  three  functional  parts  are 

Update_Delayed_Threats(); 

Process_New_Threats(); 

Test_Sensor_Coverage_Limits(); 

Each  of  these  fimctions  are  described  in  the  following  sections. 

4.1.3.3.1.1.  Update_Delayed_Threats  CSU 

Each  invocation  of  Update_Delayed_Threats  decrements  a  delay  counter 
associated  with  each  threat  in  the  wait  queue.  The  counter  symbolizes  the 
remaining  delay  time  for  a  given  threat.  The  initial  delay  time  for  each  threat 
type  is  assigned  to  each  threat  when  it  is  initially  detected  in 
Test_Sensor_Coverage_Limits . 

4.1.33.13.  Process_New_Threats  CSU 

When  the  counter  for  a  specific  threat  reaches  zero,  a  detection  probability  is 
used  by  Process_New_Threats  to  decide  if  a  threat  satisfies  the  probability  of 
detection.  A  detected  threat  is  moved  from  the  wait  queue  to  the  new  threats 
queue.  (The  new  threats  queue  will  be  examined  later  in 
Fuse_Correlate_Threats).  A  non  detected  threat  is  deleted  from  the  wait 
queue. 

Finally,  if  the  detected  threat  is  a  mine,  the  vehicle  brakes  are  applied 
immediately  . 

4.1.33.13.  Test_Sensor_Coverage_Limits  CSU 

Test_Sensor_Coverage_Limits  performs  a  series  of  tests  to  determine  if  a 
new  threat  report  is  detectable  by  a  specific  sensor.  The  logic  of 
Test_Sensor_Coverage_Limits  is  constructed  to  be  as  generic  as  possible. 
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This  means  that  tests  for  each  sensor  have  been  combined  into  a  single  set  of 
tests  which  are  applied  equally  to  all  threat  reports.  Differences  between 
individual  sensors  are  handed  by  a  table  of  sensor  behaviors  where  a  given 
entry  contains  sensor-specific  parameters.  Instances  where  tests  are 
inappropriate  for  a  specific  sensor  are  handled  by  providing  compensating 
tolerances.  For  example,  the  MWS  and  MFD  sensors  require  a  test  to 
determine  if  the  threat  is  heading  towards  the  tank.  For  these  two  sensors, 
only  threats  which  are  approaching  the  tank  within  a  narrow  approach  angle 
are  identified  as  threats.  For  sensors  not  requiring  an  approach  angle  test, 
the  widest  possible  approach  angle  is  used  (±  180“)  so  these  reports  will  not  be 
discarded  prematurely. 

Threat  reports  ‘which  pass  the  approach  angle  test  are  further  tested  to 
determine  if  the  threat  falls  within  the  current  alert  sector,  and  sensor 
azimuth  and  coverage  sector  angles.  (The  alert  sector  is  one  of  the  CCDP 
settings  and  can  be  changed  at  any  time,  whereas  the  sensor  approach, 
azimuth  and  coverage  sectors  remain  constant  during  the  simulation.) 

To  simplify  calcxilations,  the  threat  position  is  mathematically  transformed 
into  the  coordinate  system  of  the  tank  hull.  At  this  point,  the  relative  threat 
azimuth  and  elevation  angles  are  computed.  If  the  threat  is  heading  towards 
the  tardc  and  falls  within  the  alert,  sensor  azimuth  and  sensor  elevation 
coverage  sectors,  it  is  added  to  the  wait  queue  with  the  sensor-specific 
reaction/delay  time.  Otherwise,  the  threat  report  is  discarded. 

4.I.3.4.  Manage.Countermeasures  CSC 

Manage_Countermeasures  serves  as  the  primary  entry  point  for 
coimtermeasure  simulation.  Countermeasure  simulation  satisfies  the 
requirement  to  prioritize  threats,  select  appropriate  countermeasures  and  to 
activate  individual  countermeasures  for  each  threat.  These  activities  are 
accomplished  by  invoking  the  following  functions: 

Prioritize_Threats() ; 

Select_Countermeasures(); 

Update_CPS^Coverage(); 

Individual_CM_SimulO; 

Each  of  these  functioris  are  described  in  the  following  sectioris.  Note  that 
Prioritize_Threats,  Select_Countermeasures  and  Update_CPS_Coverage  are 
invoked  only  when  the  VIDS  power  is  on. 

4.I.3.4.I.  Prioritize_Threats  CSC 

Prioritize^Threats  simulates  the  behavior  of  the  VIDS  Threat  Resolution 
Module  (TRM).  Its  primary  purpose  is  to  classify  threats  based  upon  the 
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oirrent  sensor  reports.  Furthermore,  Prioritize.Threats  sorts  the  threats  so 
coimtermeasures  for  the  most  lethal  threats  will  be  activated  first.  Finally, 
threats  are  autonuitically  deleted  if  no  new  sensor  reports  are  received  within 
a  predefined  threat  lifetime. 

These  activities  are  accomplished  by  invoking  the  following  functions; 

Fuse_Correlate_Threats(); 

Sort_Prioritized_Threats(); 

Update_All_Prioritized_Threats(); 

Each  of  these  functions  are  described  in  the  following  sections.  Note  that 
Sort_PrioritizedlThreats  is  invoked  only  when  the  queue  of  active  threats 
has  changed  through  an  addition,  update  or  deletion. 

4.I.3.4.I.I.  Fuse_Correlate_Threats  CSU 

The  new  threats  queue  built  by  Process_New_Threats  is  examined  by 
Fuse_Correlate_Threats  to  determine  if  a  new  threat  report  supplies 
additional  information  for  a  known  threat.  When  a  new  report  correlates 
with  previous  reports  (specifically,  the  SIMNET  vehicle  identification  values 
match),  the  new  sensor  information  is  consolidated  with  the  previous 
ii\formation.  Sensor  detection,  energy  type  categories  (some  sensors  like 
LWR  can  detect  different  types  of  laser  energies)  and  threat  platforms  are 
combined  into  sets;  azimuth,  elevation  and  range  values  are  replaced  by  the 
current  threat  report  data.  Only  when  a  new  report  better  identifies  the  ^eat 
are  guise  and  vehicle  type  information  updated. 

When  a  new  report  does  not  correlate  with  a  known  threat,  the  report  is 
added  to  the  prioritized  threat  queue  as  a  new  threat.  Furthermore,  an  alarm 
warning  is  queued.  The  t)^e  of  alarm  warning  corresponds  to  the  detecting 
sensor. 

Get_Threat_Classification  is  invoked  for  both  updated  and  new  threats  to 
return  a  threat  classification.  The  threat  classification  is  then  used  by 
Get_Threat_Priority  to  return  a  threat  priority. 


4.I.3.4.I.2.  Get_Threat_Classification  CSU 

Get_Threat_Classification  uses  what  is  currently  known  about  a  threat  to 
assign  a  classification.  Threats  detected  by  the  NC5  or  Mine  sensor  have 
straightforward  classification  assigrunents.  However,  for  the  remaining 
sensors,  classifications  are  based  upon  moderately  complex  combinations  of 
sensor  reports.  Consequently,  the  following  PDL  succinctly  summarizes  the 
classification  strategy: 
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if  (S«nK»JRtports.MINE) 
ntunt  Cuiss_Minc; 
cndif 

if  (SmaorJicportsJsICS) 
return  ClassjChcmical; 

•tdif 

if  (Senaor JlcpOTts.MFD) 

Class  •  Class_MuzzIe;  _  , 

if  (Sensor  Jleports.LWR  Cat^iy.LRF) 

return  Glass_Muzsle_w_LRF; 
end  if 

if  (Available.CMs.TCS) 
return  Clas5_Mu22le_w_TCS; 
endtf 
and  if 


else  if  (Flatform-Tanlc) 

Class  >  Class.Tank; 
dse  if  ^tfonn  Jidkopter) 

Class  a  Class  Jiclicopter; 
endif 

if  ^ensor_Fepotts.NIS) 

Oass  a  Oass Jlelieopter: 

if  Censor  Jtcports.TRWR) 
if  (CatMorvSADAm^link) 
if  (Hamnniielkopter) 

Oass  a  Class_3;  /•AT-6V 
else 

OassaClassJ;  /•AT-2C  V 
endif 

if(PlatfQrm.Unknown)  _  _  _ 

Class  a  Class_6;  /•  AT-2C  or  AT-6  V 
endif 

if  (Platform  Jnfantry_Support) 

Class  a  Oass  Jnnnt^_Support; 
endif 
endif 
endif 

if  Censor  Jleports.MWS) 
aa58aClaM_9;  /’AnyATCMV 

ifOAvailable  Sensors.LWR&  !Sensor_ReportsTRWR) 
Class  a  aass_7;  /•  AT-4,  AT-9,  or  AT-11  •/ 
endif 


if  (!Available_Sensors.TRWR) 

Oass  a  ClassJS;  /*  AT-2C,  AT-4,  or  AT-6  V 
else  if  (!SensorjR^rts.TRWR) 
ClassaClass_2;  /•AT-4V 
endif 
endif 
endif 

if  (Sensor  Jleports.LWR) 
if  (Categoty.LDES) 

ciS  a  Class_4;  /•AT-9V 


ClassaClass.5;  /•  AT-11  V 
else  if  (CaterciylRF) 

Class  -  Oass.lO;  /•  general  threat  •/ 
endif 
endif 

return  Class; 
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4.1.3.4.13.  Get.Threat_Priority  CSU 

Get.Threat_Priority  is  a  simple  function  which  uses  the  supplied  threat  class 
as  index  into  a  table  of  priorities.  The  priority  for  a  given  threat  class  is 
contained  in  VIDS.D.  A  copy  of  VIDS.D  is  included  as  Appendix  A. 

4.13.4.1.4.  Sort_Prioriti2ed_Threats  CSU 

Sort_Prioritized_Threats  visits  each  threat  in  the  prioritized  threat  queue  to 
verify  each  threat  is  positioned  correctly  within  the  queue.  Threats  which 
have  activated  a  countermeasure  are  placed  lower  in  the  queue  than  threats 
which  have  not.  A  threat  which  is  inside  the  safety  sector  is  lower  in  priority 
than  one  which  is  outside.  When  two  threats  have  equal  priority,  the  one 
which  is  closest  to  the  main  gun  has  higher  priority.  When  two  threats  are 
equal  in  angular  proximity  from  the  main  gun,  the  one  which  will  be  reached 
first  with  a  clockwise  turret  rotation  has  higher  priority. 

4.1.3.4.13.  Update_All_Prioritized_Threats  CSU 

Update_All_Prioritized_Threats  visits  each  threat  in  the  prioritized  threat 
queue  to  decrement  its  lifetime.  When  the  lifetime  for  a  threat  reaches  zero, 
it  is  removed.  Since  this  changes  the  status  of  the  prioritized  threat  queue,  a 
new  prioritized  threat  message  is  sent  to  the  CCDP  so  that  the  corresponding 
threat  icon  will  be  removed. 

4.I.3.4.2.  Select.Countermeasures  CSU 

Select_Countermeasures  assigns  countermeasures  to  new  threats  and 
reconfirms  that  the  current  coimtermeasure  for  an  existing  threat  is  correct. 
This  is  done  by  visiting  each  threat  in  the  prioritized  threat  list  'and 
determining  if  it  has  been  assigned  a  countermeasure.  When  a 
coimtermeasure  has  not  been  assigned,  a  table  lookup  is  used  to  find  the  first 
available  countermeasure.  When  a  countermeasure  has  been  assigned,  a 
table  lookup  is  still  performed  to  confirm  that  the  same  countermeasure  is 
still  recommended.  This  is  done  because  the  type  of  threat  may  have  changed 
due  to  sensor  fusion  or  because  an  expendable  countermeasure  is  no  longer 
available.  If  the  recommended  countermeasure  has  changed,  the  new 
recommended  countermeasure  will  be  activated  even  if  the  previous 
countermeasure  has  been  activated. 

Once  each  threat  has  been  assigned  a  countermeasure,  a  check  is  made  to 
determine  if  there  has  been  a  manual  change  in  the  order  of  countermeasure 
activatioa  If  the  CCDP  settings  indicate  a  change,  the  corresponding 
countermeasure  will  be  activated  first  in  Individual_CM_Simul. 
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4.13.4.3.  Updake_CPS_Coverage  CSU 

Update_CPS_Coverage  converts  the  CPS  azimuth  coverage  sector  from  the 
current  CCDP  control  settings  and  replays  the  current  CPS  azimuth  coverage 
values.  The  changed  azimuth  coverage  values  will  be  retrieved  the  next  time 
CPS  is  activated  as  a  countermeasure. 

4.I.3.4.4.  Individual_CM_Simul  CSU 

Individual_CM_Simul  controls  the  activation  and  deactivation  of 
countermeasures.  In  general,  individual  countermeasures  are  activated  and 
deactivated  simultaneously  until  all  threats  have  been  handled.  Only  w'hen 
an  individual  countermeastire  is  needed  to  defeat  multiple  threats  is  the 
countermeasure  activated  sequentially.  Furthermore, 

Individual_CM_Simul  supports  automatic  modes  for  counterfire  rotation 
and  turret  slewing. 

Countermeasure  activation,  coxmterfire  rotation  and  turret  slewing  can  all  be 
activated  automatically  or  semi-automatically.  (Semi-automatic  activation  is 
equivalent  to  automatic  activation  when  the  commanders  thumb  switch  is 
engaged.)  Cotmtermeasures  can  be  activated  manually  using  buttons  on  the 
CCDP,  but  manual  coxmterfire  rotation  and  turret  slewing  is  still  controlled  by 
either  the  tank  commander  oi  gunner  controls.  Note,  however,  that  all 
coimtermeasure  activations  require  arming.  A  button  on  the  CCDP  arms  all 
countermeasures . 

Manual  countermeasure  activation  occurs  when  countermeasures  are  armed 
and  a  countermeasure  button  is  depressed  (back  lighted)  on  the  CCDP. 
Electro-optical  countermeasure  energy  is  transmitted  endlessly  until  either 
the  corresponding  button  is  released  or  coimtermeasures  are  made  safe 
(disarmed).  Manual  ROS  activation  launches  a  salvo  of  grenades  within 'the 
CM  Coverage  sector.  Manual  chaff  or  flares  activation  launches  all 
expendables  at  once.  Furthermore,  manual  jamming  or  a  salvo  of  smoke 
grenades,  chaff  or  flares  can  occur  concurrently  widi  any  mode  of  turret 
slewing. 

Automatic  countermeasure  activation  occurs  when  all  of  the  following 
conditions  exist: 

a.  the  CM  mode  is  automatic  or  semi-automatic. 

b.  the  recommended  countermeasure  for  a  threat  is  available. 

c.  countermeasures  are  armed. 

d.  the  commanders  thumb  switch  is  engaged  (necessary  only  for  semi¬ 
automatic  activation). 

Furthermore,  if  a  countermeasure  requires  turret  rotation  prior  to  activation, 
automatic  modes  for  both  counterfire  rotation  or  turret  slewing  are 
temporarily  suspended. 
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Automatic  rotation  for  counterfilre  will  occur  when  the  following  conditior\s 
exist: 

a.  the  CFIRE  mode  is  automatic  or  semi-automatic. 

b.  automatic  countermeasure  activation  has  not  seized  control  of  the 
turret. 

c.  the  commanders  thumb  switch  is  engaged  (necessary  only  for  semi¬ 
automatic  activation). 

Automatic  turret  rotation  temporarily  suspends  automatic  turret  slewing. 

Automatic  turret  slewing  will  occur  when  the  following  conditions  exist: 

a.  the  SCAN  mode  is  automatic  or  semi-automatic. 

b.  automatic  countermeasure  or  counterfire  rotation  has  not  seized 
control  of  the  turret. 

c.  the  commanders  thumb  switch  is  engaged  (necessary  only  for  semi¬ 
automatic  activation). 

The  following  countermeasures  are  simulated:  ROS,  MCD,  CPS,  ATRJ, 
LCMD,  VEMASID,  TCS,  NBCOP,  Chaff /Hares.  Furthermore,  the  radar  search 
energy  of  the  FASR  sensor  and  the  forward-looking  infrared  (FLIR)  energy  of 
the  MINE  sensor  are  simulated  here.  However,  to  simplify  their  design, 
countermeasures  have  been  simulated  by  generic  CSUs.  Those 
countermeasures  which  have  similar  operating  characteristics  have  been 
grouped  together.  The  modules  and  the  countermeasures  they  simulate 
follow: 

a.  ROS_Simul:  ROS. 

b.  EO_CM_Simul:  MCD,  CPS,  ATRJ,  LCMD,  VEMASID,  the  radar  search 
energy  of  the  FASR  sensor,  and  the  FLIR  energy  of  the  MINE  sensor. 

c.  TCS_SimuI:  TCS. 

d.  Decon_CM_Simul:  NBCOP. 

e.  One_Shot_CM_Siinul:  Chaff  and  Hares. 

Each  of  these  modules  are  described  in  the  following  sections. 

4.I.3.4.4.I.  ROS.Simul  CSU 

ROS^Simul  serves  as  the  primary  entry  point  for  simulation  of  the  Rapid 
Obscuration  System  (ROS).  Tliis  system  launches  smoke  grenades  to 
temporarily  hide  the  tank  position  from  electro-optically  guided  or  terminal 
homing  missile  threats. 

For  simulation,  the  turret  is  conceptually  divided  into  24  equal  sectors  each 
with  15  degrees  of  coverage.  Each  sector  may  contain  zero  or  more  grenades; 
and  there  may  be  more  than  one  smoke  grenade  type  for  individual  sectors. 


-18- 


VIDS  SDD 


For  manual  activation,  the  number  and  sectors  are  specified  by  the  CCDP 
coimtermeasure  coverage  sector.  Smoke  grenades  are  launched  a  predefined 
distance  from  the  tank  hull. 

For  automatic  activation,  launch  sectors  are  selected  dynamically.  Launch 
sectors  are  selected  which  require  the  minimum  turret  rotations  to  get  the 
recommended  smoke  greiuides  between  the  threat  and  the  tank  hull.  Once 
the  turret  has  rotated  a  launch  sector  into  position,  one  or  more  grenades  are 
launched  from  adjacent  sector  positions.  Note  that  if  turret  rotation  is 
required  by  ROS,  guzmer  and  commander  turret  controls  are  disabled;  and 
automatic  rotation  for  counterfire  or  turret  slewing  is  temporarily  suspended. 

As  grenades  are  launched,  the  inventory  of  available  smoke  grenades  is 
decremented.  Once  all  the  recommended  grenades  have  been  launched,  the 
prioritized  threat  record  is  updated  so  that  additional  smoke  grenades  will  not 
be  launched  towards  the  same  threat;  gunner  and  commander  turret  controls 
are  reenabled;  and  automatic  rotation  for  counterfire  or  turret  slewing  is 
resumed. 

4.1.3.4.4JL  EO_CM_Simul  CSU 

EO_CM_Simul  serves  as  the  primary  entry  point  for  simulation  of  the  MCD, 
CPS,  ATRJ,  LCMD,  VEMASID,  the  radar  search  energy  of  the  FASR  sensor 
and  the  FLIR  energy  of  the  MINE  sensor.  This  module  simulates  systems 
which  direct  electro-optical  energy  towards  a  threat. 

Because  of  independent  slewing,  the  center  of  the  electro-optical  energy  is  in 
one  of  two  directions.  In  manual  mode,  the  countermeasure  slew's  to  be 
coincident  with  the  direction  of  the  main  gim;  in  an  automatic  mode,  the 
countermeasure  slews  to  angle  of  the  detected  threat. 

Electro-optical  begms  when  the  countermeasure  device  arrives  at  the  required 
azimuth  angle  and  when  the  reaction/delay  time  has  expired.  For  manual 
activation,  ^e  jamming  energy  continues  until  it  is  manually  deactivated. 
For  automatic  activation,  the  electro-optical  continues  until  the  predefined 
jamming  time  expires.  Furthermore,  the  prioritized  threat  record  is  updated 
so  that  jamming  energy  will  not  be  automatically  directed  against  the  same 
threat. 

The  radar  search  energy  from  the  FASR  sensor  begins  only  when  the 
corresponding  CCDP  button  is  depressed  and  after  the  reaction/ delay  time  has 
expired.  The  center  of  radar  search  energy  is  always  aligned  with  the  main 
gtm.  Releasing  the  FASR  button  immediately  terminates  the  radar  search 
energy. 
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The  FLIR  energy  from  the  MINE  sensor  begins  only  when  this  sensor  is 
available  and  when  the  reaction/delay  time  has  expired.  Since  the  MINE 
sensor  is  not  manually  activated/ deactivated,  the  FLIR  energy  continues  as 
long  as  the  tank  is  operational. 

4.13.4.43.  TCS.Simul  CSU 

The  function  TCS_is_Not_Effective  serves  as  the  main  entry  point  for  the 
TCS  simulation.  It  is  invoked  by  failure_check_cat_kill  (found  in  the 
ml^failure  module)  when  it  is  necessary  to  compute  damages  from  the 
impact  of  a  missile  or  main  gun  round.  If  TCS  is  not  available  as  a 
countermeasure,  damage  calculations  are  computed  normally.  However, 
when  TCS  is  available  a  series  of  tests  are  performed  to  determine  if  the 
impact  should  be  ignored. 

The  first  set  of  tests  determine  if  TCS  is  in  a  ready  mode.  TCS  is  in  a  ready 
mode  if  the  following  conditions  are  satisfied: 

a.  countermeasures  are  armed,  and 

b.  the  CM  mode  is  automatic,  or 

the  CM  mode  is  semi-automatic  and  the  commanders  thumb  switch  is 
engaged,  or 

c.  the  CM  mode  is  manual  the  TCS  button  is  depressed. 

If  the  TCS  is  in  the  ready  mode,  the  final  set  of  tests  are  performed. 
Conceptually,  the  hull  is  divided  into  quadrants:  front  right,  front  left,  rear 
left,  rear  right.  The  direction  of  the  velocity  vector  of  ^e  projectile  with 
respect  to  the  hull  orientation  is  used  to  derive  which  quadrant's  inventory 
must  be  examined.  If  the  quadrant's  inventory  is  not  depleted,  the  inventory 
is  reduced  by  one  and  TCS  has  saved  the  tank  crew  from  a  catastrophic  kill. 

4.I.3.4.4.4.  Decon_CM_Simul  CSU 

Decon_CM_Shnul  and  Poison_Simul  serve  as  the  primary  entry  points  for 
simulating  the  NBCOP.  Identify_Threats  registers  when  a  poison  is  present 
regardless  of  the  availability  of  NCS  by  invoking  Contaminant_Exists. 
When  poison  is,  present,  Poison_Simul  decrements  a  life-expectancy  timer. 
A  catastrophic  kill  is  initiated  when  the  timer  expires. 

Decontamination  begins  when  the  following  conditions  are  satisfied: 

a.  coimtermeasures  are  armed  and, 

b.  the  CM  mode  is  automatic,  or 

the  CM  mode  is  semi-automatic  and  the  commanders  thumb  switch  is 
engaged,  or 

c.  the  CM  mode  is  manual  and  the  NBCOP  button  is  depressed. 
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For  manual  activation,  the  decontamination  continues  until  it  is  manually 
deactivated.  For  automatic  activation,  the  jamming  continues  until  the 
predefined  jamming  time  expires. 

4.1.3.4.4.5.  One_ShoLCM_Simul  CSU 

One_Sfiot_CM_Siniul  serves  as  the  primary  entry  point  for  Chaff  and  Flares 
coimtermeasure  simulation.  This  module  launches  chaff  or  flares  to  decoy 
radar  directed  or  infira-red  guided/directed  missiles  and  munitions. 

Because  of  independent  slewing,  the  final  azimuth  launch  angle  is  in  one  of 
two  directions.  In  manual  mode,  the  coimtermeasure  slews  to  be  coincident 
with  the  direction  of  the  main  gun;  in  an  automatic  mode,  the 
countermeasure  slews  to  azimuth  angle  of  the  detected  threat. 

Chaff  or  flares  are  launched  as  soon  as  the  countermeasure  device  arrives  at 
its  prescribed  angle  and  when  the  reaction  delay  time  has  expired.  For 
automatic  activation,  the  prioritized  threat  record  is  updated  so  that  other 
countermeasures  will  not  be  automatically  directed  against  the  same  threat. 
Furthermore,  once  chaff  or  flares  are  launched,  the  entire  chaff  or  flares 
inventory  is  considered  to  be  depleted. 

4.1.3.4.4.6.  CFire.Simul  CSU 

CFire_Simul  serves  as  the  main  entry  point  of  automatic  turret  slewing  for 
counterfire.  This  module  rotates  the  turret  to  aim  the  main  gun  in  the 
direction  of  a  threat. 

As  automatic  turret  rotation  begins  the  gurmer  and  commander  turret 
controls  are  disabled.  Once  the  main  gim  is  positioned  to  the  threat  azimuth 
angle,  gunner  and  commander  turret  controls  are  reenabled. 

As  a  final  note,  the  main  gun  is  never  fired  automatically. 

4.1.3.4.4.7.  Turret_Scanning_Simul  CSU 

Turret_ScanningiLSimul  serves  as  the  main  entry  point  of  automatic  turret 
slewing.  This  module  rotates  the  turret  within  the  turret  scanning  sector. 

As  automatic  turret  rotation  begins  the  gurmer  and  commander  turret 
controls  are  disabled.  Only  when  automatic  turret  scanning  is  disabled  are  the 
gurmer  and  conunander  turret  controls  reenabled. 


4.I.3.5. 
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S€nd_Updates_to_CCDP  serves  as  the  primary  communicatior\  channel  for 
sending  information  updates  from  the  VIDS-GT  to  the  VIDS-PC.  The 
following  types  of  information  are  sent; 

a.  changes  to  the  top  ten  threats. 

b.  changes  to  hull  or  turret  orientations. 

c.  changes  to  master  or  turret  power  states. 

d.  audible  alerts  for  new  or  changed  threats. 

e.  changes  in  expendable  countermeasure  (ROS,  TCS,  Chaff/Flares) 
inventory. 

Services  provided  by  existing  code  are  used  to  package  and  transmit  the 
messages  to  the  corresponding  VIDS-PC. 

4.1.3.6.  Send_Updates_to_Network  CSC 

Send_Updates_to_Network  serves  as  the  primary  communication  channel 
for  sending  the  state  of  the  VIDS-equipped  tank  to  other  entities  participating 
within  the  same  simulated  battle  exercise.  The  following  types  of 
informational  messages  are  sent: 

a.  the  presence  of  smoke,  chaff  or  flares. 

b.  the  activation/deactivation  of  electro-optical  energy. 

c.  instrumentation  (used  only  for  data  collection  and  analysis). 

Only  instrumentation  messages  are  sent  at  regular  intervals.  However,  an 
instrumentation  message  will  be  sent  sooner  if  one  of  the  following 
conditions  exist: 

a.  the  state  of  the  Master  or  Turret  Power  changes. 

b.  the  state  of  the  commander's  thumb  switch  changes. 

c.  the  number  of  threats  exceeds  the  maximum  number  of  display  able 
icons  on  the  CCDP. 

d.  turret  control  is  seized  or  released  by  VIDS. 

Services  provided  by  existing  code  are  used  to  package  and  transmit  the 
information  to  other  entities. 

4.1.3.7.  Need_To_Release_Turret  CSU 

Need_To_Release_Turret  provides  a  safeguard  to  release  turret  control  when 
no  threats  are  present  and  CM,  CFLRE  and  SCAN  modes  are  in  manual. 

4.1.3.8.  CM_Rotation_Simul  CSC 
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CM_Rotation_Siniul  supports  the  need  for  independently  slewing 
countermeasures.  Furthermore,  it  manages  conflicting  rotation  requests 
using  priorities. 

Each  independently  slewing  countermeasure  corresponds  to  an  entry  in  the 
countermeasure  device  table.  For  each  invocation  of  CM_Rotation_Simul, 
individual  coimtermeasure  devices  are  rotated  to  the  next  position  by  adding 
the  device  rotation  rate  to  the  current  position.  The  rotation  rate  can  be 
positive  or  negative  to  move  a  device  in  a  specific  angular  direction.  Because 
all  simulated  devices  (except  VEMASID)  are  mounted  to  the  turret,  hull  and 
turret  rotations  can  accelerate  or  retard  the  time  required  to  move  a  device  to 
a  specified  angle.  However,  once  the  device  has  arrived,  it  remains  perfectly 
positioned  until'a  higher  priority  request  is  received. 

Conflicting  requests  to  rotate  a  specific  countermeasure  are  handled  using 
priorities.  The  priority  of  each  countermeasure  rotation  request  is  compared 
to  the  previous  rotation  request.  Lower  priority  requests  are  ignored.  A 
request  with  equal  or  higher  priority  than  the  current  priority  takes  control  of 
the  countermeasure  device.  The  new  priority  replaces  the  current  priority. 

4.1.3.9.  Turret_Rotation  CSC 

Start_Turret_Rotation  and  Stop_Turret_Rotation  serve  as  the  main  entry 
points  for  automatic  turret  rotations  required  by  ROS_Simul,  CFire_Siniul 
and  Turret_Scarming_Simul.  Like  CM_Rotation_Siinul,  rotation  requests 
are  based  upon  a  priority. 

Conflicting  requests  to  rotate  the  turret  or  stop  the  current  rotation  are 
handled  using  priorities.  The  priority  of  each  turret  request  is  compared  to 
the  previous  request.  Lower  priority  requests  are  ignored.  A  request  with 
greater  than  or  equal  to  the  current  priority  takes  control  of  the  turret.  The 
new  priority  replaces  the  current  priority. 

Start_Turret_Rotation  is  invoked  to  initiate  automatic  turret  rotation.  The 
minimum  rotation  direction  is  computed  using  the  current  and  final  turret 
p>ositions  when  the  request  satisfies  the  priority  test.  The  direction  is  used  to 
compute  the  sign  of  the  turret  rotation  increment.  It  is  this  increment  which 
is  used  to  modify  the  current  turret  position  during  each  execution  cycle. 

Stop_Turret_Rotation  is  invoked  to  terminate  automatic  turret  rotation. 
Only  when  the  request  satisfies  the  priority  test  is  the  automatic  turret 
rotation  terminated. 

4.1.3.10.  VIDS_Shutdown  CSC 
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The  VIDS_Shutdown  CSC  handles  the  job  of  shutting  down  the  VIDS 
simulation.  The  local  Master  and  Turret  Power  states  are  cleared  and  the 
final  power  state  message  is  sent  to  the  CCDP.  This  has  the  net.  effect  of 
forcing  the  CCDP  to  redisplay  the  iiutial  (power  off)  menu. 

Each  internal  queue  is  examined  and  each  member  is  formally  deallocated. 
Once  this  is  complete,  memory  statistics  are  written  to  the  main  console.  The 
statistics  can  indicate  if  there  is  a  memory  management  problem  or  if 
additional  memory  should  be  preallocated  during  the  earlier  execution  of 
VIDS.Init. 

4.1.4.  XFieldCSC 

XField  handles  the  low-level  simulation  of  electro-optical  energy.  XField 
PDUs  retrieved  from  the  network  are  examined  to  determine  the  kind  and 
spatial  extent  of  electro-optical  energy.  If  the  VIDS-equipped  tank  falls  within 
the  energy  field,  the  information  describing  the  field  is  added  to  an  internal 
list  of  o^er  fields.  Additionally,  the  presence  of  clouds  (smoke)  is  used  to 
determine  if  the  field  energy  is  absorbed.  If  field  energy  is  absorbed,  the  field 
is  not  made  available  to  the  higher-level  Identify_Threats  CSC. 

Fields  are  removed  from  the  list  when  either  an  explicit  XField  PDU  defines 
that  the  field  no  longer  exists  or  the  specified  field  liktime  expires. 

An  XField  PDU  sent  by  the  VIDS-equipped  tank  (refer  to  the 
EO_Sensor_Simul  and  One_Shot_CM_Simul  CSUs)  is  tagged  appropriately 
to  distinguish  it  from  fields  sent  by  other  vehicles.  Furthermore  this  type  of 
field  is  periodically  retransmitted  to  the  network  as  long  as  the  field  is 
present. 

4.1.5.  Qoud  CSC 

Cloud  handles  the  low-level  simulation  of  electro-optic  energy  absorbing 
smoke  clouds.  Smoke  Cloud  PDUs  are  initially  transmitted  to  the  network  by 
VIDS-equipped  tanks  (refer  to  the  ROS^Simul  CSU)  to  iriform  other  vehicles 
that  new  smoke  clouds  exist. 

Each  smoke  grenade  is  simulated  as  a  single  cloud.  Parameters  are  supplied 
which  define  the  smoke  type  and  corresponding  spatial  dynamics.  This 
allows  other  vehicles  to  model  the  smoke  growth,  dissipation  and 
interference  with  electro-optical  energy. 

Like  XFields  PDUs,  Cloud  PDUs  are  periodically  retransmitted  to  the  network 
as  long  as  the  smoke  is  potentially  effective  as  an  obscurant.  When  the 
smoke  from  a  grenade  is  no  longer  effective,  a  Cloud  PDU  is  transmitted  to 
the  network  so  that  other  vehicles  can  drop  it  from  their  internal  lists. 
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4.1.6.  Modifications  to  Existing  Code 

Modifications  to  existing  code  were  made  to  support  the  VIDS-GT  capability. 
The  files  and  changes  follow: 

a.  ml_main.c 

Added  invocation  of  VIDS_Init  in  the  veh_spec_init  function. 

Added  invocation  of  VIDS_File_Read  in  the  veh_spec_startup. 

Added  invocation  of  VIDS_Simul  in  the  veh_spec_simulate. 

Added  VIIDS_Shutdown  to  the  veh_spec_exit  to  send  a 
TankPowerStateVariantmsg  to  the  CCDP  to  turn  it  off. 

Added  a  test  to  determine  if  the  engine  was  miming  before  invoking 
VIDS_Siniul()  to  support  the  NIS-unique  detection  and  identification 
probabilities. 

Made  changes  to  access  new  idc_value  array  element  which  holds  the 
state  of  the  new  commander's  thumb  switch. 

Inserted  field_tick  and  cloud_tick  before  VIDS_Sin\ul. 

b.  ml_turret.c 

Added  the  set_vids_a2  function  to  support  automatic  turret  rotations 
to  specific  azimuth  angles. 

Added  the  set_vids_relative  function  to  support  final  turret  angles 
relative  to  the  tank  hull. 

Added  the  set_vids_north  function  to  support  final  turret  angles 
relative  to  true  north. 

Added  the  set_vids_auto_on  function  to  disable  the  gunner  and 
commander  turret  rotation  controls. 

Added  the  set_vids_auto_off  function  to  enable  the  gunner  and 
commander  turret  rotation  controls. 

Added  the  set_vids_slew_rate  function  to  support  the  specification  of 
a  rotation  rate. 

Added  the  get_vids_rate  function  to  retrieve  the  current,  VIDS-specific 
turret  rotation  parameters. 

c.  proc_a_pkt.c 

Added  code  to  recognize  and  reformat  VXDS  (CCDP  Control  Settings) 
PDUs. 

Added  code  to  recognize  ROS,  TCS  and  Chaff/ Flares  munition 
resupply  PDUs  so  the  initial  supply  and  placement  of  expendable 
countermeasures  could  be  instantly  restored. 

d.  ml_ctl_tpc.c 

Made  changes  to  support  the  use  of  a  new  commander's  thumb  switch 
which  will  be  used  instead  to  activate  semi-automatic  CMs. 

e.  ml_failure.c 

Added  the  TCS_is_Not_Effective  function  to  intercept  a  fatal  impact 
from  a  missile  or  projectile. 

f.  ml_resupp.c 
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Added  code  to  recognize  the  ROS,  TCS  and  Chaff/Flares  variants  of  the 
munition  resupply  PDU  and  invoke  the  corresponding  CSC  resupply 
functions, 
g.  read_pars.c; 

Added  code  to  recognize  and  store  the  name  of  the  VIDS  parameter 
fUe. 

Added  get_vids_data_file  to  return  the  name  of  the  VIDS  parameter 
file. 

42.  VIDS>FC  Detailed  Design 

42.1.  SMIJnitCSC 

SMI^Init  preallocates  dynamic  memory  structures  associated  with  drawing 
menus  and  icons  which  will  be  displayed  during  the  execution  of  the 
SMI_Siniul  CSC.  Data  files  are  read  which  define  the  placement  and 
appearance  of  buttons  and  icons  as  well  as  the  unique  identifier  (VehiclelD)  of 
the  corresponding  GT.  Parameters  are  read  which  define  active  buttons  and 
how  long  they  must  be  pressed  for  a  corresponding  action  to  be  activated. 
VIDS  (Default  Sector  Setups  and  Expendable  CM  Inventory)  PDUs  sent  by  the 
corresponding  GT  supplies  iiutial  values  for  the  alert,  countermeasure,  safety, 
scaiming  and  CPS  coverage  sectors,  the  list  of  available  serisors  and 
coimtermeasures  and  the  inventory  of  the  expendable  countermeasures.  The 
list  of  available  countermeasures  is  used  assign  spare  buttons  to  individual 
countermeasures.  Finally,  links  are  established  betw'een  buttons  and  function 
invocations. 

422,  SMI.SimulCSC 

SMI_Siinul  serves  as  the  primary  entry  point  for  simulation  of  the  real 
CCDP.  It  represents  the  root  of  a  functional  hierarchy  which  is  executed 
endlessly  imtU  a  keyboard  Control-C  or  right  mouse  button  event  is  received. 
During  a  single  execution  cycle,  the  following  high-level  functions  are 
executed: 

Get_Button()'; 

Check_Alarms(); 

Process_Rcv_PDU(); 

Each  of  these  functions  represent  a  functional  sub-hierarchy  which  is 
described  in  the  following  sections. 

42.2.1.  Get.Button  CSU 

Get_Button  serves  the  need  to  monitor  button,  mouse,  and  keyboard  activity. 
A  right  mouse  button  or  keyboard  Control-C  signals  a  request  to  terminate 
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the  SMI^Simul  CSC  by  transitioning  to  SMI_Shutdown.  Otherwise,  a  test  is 
made  to  determine  if  a  displayed  button  has  been  held  down.  If  a  button  has 
been  held  down  long  enough  and  it  corresponds  to  a  predefined  action,  the 
action  is  initiated  through  a  corresponding  function  call.  The  corresponding 
function  may  change  the  current  menu,  the  content  of  the  display,  the 
operating  state  or  a  combination  of  these  changes.  When  a  button  changes 
one  of  the  VIDS  operating  states,  a  network  message  is  sent  to  the  VIDS-GT  to 
update  its  corresponding  CCDP  settings  Additionally,  when  any  button  state 
is  changed  or  when  a  user  alert  message  is  displayed,  an  instrumentation 
message  is  sent  to  the  network  for  data  collection  and  analysis. 

i.2JL2.  Check.Alarms  CSU 

Cheeky  Alarms  manages  the  VIDS  alarm  tones  heard  on  the  tank  intercom. 
The  status  of  each  alarm  type  is  checked  to  determine  if  it  should  be  activated 
or  terminated.  When  an  alarm  is  activated,  the  alarm  is  heard  for  a 
predefined  duration.  An  alarm  is  terminated  when  the  duration  has  expired, 
a  termination  message  was  received  from  the  GT  or  VIDS  is  powered  off. 

4.2.13.  Process_Rcv_PDU  CSC 

Process_Rcv_PDU  manages  received  network  messages.  Only  messages  sent 
by  the  corresponding  VIDS-GT  are  processed.  All  other  messages  are 
discarded. 

Depending  upon  the  type  of  message,  the  display  or  alarm  tones  are  changed. 
The  message  t5rpes  which  change  the  display  include  the  following: 

a.  Teink  Power  State  updates. 

b.  Tank  Orientation  updates. 

c.  Prioritized  Threat  updates. 

d.  Automatic  CM  Activation/Deactivation  updates. 

e.  Default  Setups. 

f.  Changes  to  ^e  inventory  of  expendable  countermeasures. 

Only  the  Alarm  Control  message  type  affects  what  is  heard  on  the  tank 
intercom.  Refer  to  the  IDD  in  section  5  for  the  exact  content  of  each  message 
type. 

43.3.  SMI_Shutdown  CSU 

SMI_Shutdown  releases  memory  allocated  during  SMIJnit  and  restores  the 
mouse  and  display  behaviors  before  terminating. 
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5.  CSadata. 

Within  the  VTDS-GT  CSC,  there  is  oiUy  one  global  data  element:  vids_debug. 
It  a  Boolean  object  which  is  toggled  between  two  states  to  either  activate  or 
deactivate  diagnostic  messages.  Under  normal  conditions,  vids_debug  is 
false. 

Within  the  VIDS-PC  CSC,  the  following  arrays  represent  global  elements: 

a.  Icon. 

b.  Threat. 

c.  Frame. 

d.  Display. 

e.  Vary. 

f.  Buttons. 

g.  fcnptrs. 

These  arrays  used  to  support  low-level  drawing  operations.  Refer  to  the 
following  header  files  for  more  details: 

globaLh 
alarm  .h 
buttons.h 

The  following  table  lists  the  type  and  content  of  the  messages  exchanged 
between  the  PC,  GT  and  SAF.  Additionally,  the  content  of  Ae  GT  and  PC 
instrumentation  messages  are  included. 
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6.  CSQ  data  files. 

Files  are  not  shared  between  VIDS  CSCs  or  CSUs. 

7.  Reqtiirements  traceability. 

The  following  table  depicts  the  requirements  traceability.  The  requirements 
are  grouped  into  sections  representing  incremental  refinements.  For 
example,  requirements  beginning  with  the  number  1  signify  Phase  1 
requirements;  requirements  begirming  with  the  number  2  signify  Phased  2 
requirements.  • 
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Provide  a  VtOS  equipped  eombal  vehicle. 


ror  CPS,  show  FieM  ol  Regard  (in  degrees). 


2.16  |Provkl«  th«  followtng  VEMASIO  CM  fundkms. 
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I  8.  Notes. 


Acronyms 

Definitions 

ATRJ 

Advanced  Threat  Radar  Jammer 

AVSE 

Armored  Vehicle  Survivability  Equipment 

CCDP 

Commander's  Controls  Display  Panel 

CFIRE 

Covinterfire 

CM 

Countermeasure 

CPS 

Combat  Protection  System 

CSC 

Computer  Software  Component 

CSCI 

Computer  Software  Configuration  Item 

CSU 

Computer  Software  Unit 

FASR 

Future  Armored  System  Radar 

FLIR 

Forward  Looking  Infrared 

GT 

Graphics  Technologies 

IDD 

Interface  Description  Document 

LCMD 

Laser  Coimtermeasure  Device 

LWR 

Laser  Warning  Receiver 

MCC 

Management  Command  and  Control 

MCD 

Missile  Countermeasure  Device 

MFD 

Muzzle  Flash  Detector 

MWS 

Missile  Warning  System 

NBCOP 

Nuclear  Biological  Chemical  Overpressure 
System 

NCS 

Nuclear  Chemical  Sensor 

NIS 

Non-Imaging  Sensor 

PC 

Personal  Computer 

ROS 

Rapid  Obscuration  System 

SAF 

Semi-Automated  Forces 

see 

Simulation  Control  Console 

SIMNET 

Simulation  Network 

SMI 

Soldier  Machine  Interface 

TCS 

Threat  Countermeasure  System 

TRWR 

Tank  Radar  Warning  Receiver 

VehiclelD 

An  integer  triplet  consisting  of  site,  host  and 

vehicle  numbers.  Used  to  uniquely  identify 
an  entity  within  a  battle  exercise. 

VEMASID 

Vehicle  Magnetic  Signature  Duplication 

VIDS 

Vehicle  Integrated  Defense  System 
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Appendix  A.  Sensor/Countenneasure  Configuration  File  Content 


f  Thi*  i*  tht  VIDS  data  file  It  ia  read  at  uartup. 
fAlIdaiaaltaMniaatcpracadadbyalabd.  Aftarthc label 
f  there  will  be  one  or  mora  data  v^aa  which  will  be  ddimiicd 
•  bytabe  Any  charactecainaertcd  between  taba  will  be 
f  conaidcrad  to  be  a  data  value  (even  a  blank  apace). 

« 

f  All  dme.  angular  meaaurementa,  probabilitiei  and  diaiances 
f  am  defined  aa  floating  point  valuee 


VID5_CbiiaolaLSite 

VIOS_Conaoie_Hoat 

VIDS_Cbnaole.Vchicle 

* 

Availab)c..Senaots 

Availabie_CMs 

Auto.Activated_Qda 

« 

Max_Threata 

t 

VIDS_Proceseing.Delay 

« 

f  Senaor  Parameteis 

I 

MW5.KcaponjeLjiineJn.jec 
MWS.AIarin_DurationJn_acc 
MWSLMa]t.Oeiection_DiatanceJnjneter 
MWSJiifax^pproach_AngieJn_Dcg 
MWS>zlinu^Covcrage_Centtal_AngieJn_Ocg 
MWSAai0iuth_Covcrage_Delta_in_O^ 
MW5.Elevation_Covcragc_Central.>ji^e_in_Deg 
MWS.Eicvation_Covetagc_Delta.in_D^ 
MWS.Dctactior.J’tababUi^ 
MWS.I>ctectk>n_\ccuracyJn_Deg  i 

MWS-UftLCountdownJnjec  — 

f  ' 

LWKKcaponae_Tiinc.in_aec 
LWlK.A]artn_Duradon_in_aec 
LWRAziinuih_Coverage_Ccntral..AngleJn_Deg 
LWR.Aziinuth_Coverage_Dclta_in_Deg  .. 

LWR.Bcvation_Covetage_Ccntral_An^e_in_Deg 
I.WR.Elevation_Covetage_I>elta_in_D^ 
LWR.I>etection_ProbabUityJLRF 
LWR.Deteeiiofi_Ptobabili9_LBR 
LWR.I>Maction_Probabili7_LDE5 
LWKDetKtion..AccuracyJn_Deg 
LWR.UIe_CoontdownJn_aec 
« 

FASRJteq>once_TlinOn_aec 

FASR.A)artn_OurationJn_aec 

FASRMa]tJ>eiection_DiatanceJnjneter 

FASItA2iinuth_Coverage_CentraLAngleJn_Deg 

FASllAziinuth_Cbverage_Delu_in_D^ 

FASR.Bevation_Covetage_CentraLAn^e_m_Deg 

FASR.Elevation_Covetage_Delta_in_Deg 

FASR.DetecdonJ’robability 

FA5RJdendfication_PTobabillty 

FASR.I>tection^ccutacyJn_Deg 

FASR.UpdateJcequencyJn_sec 

FASR.Ufe_CountdownJn.jec 

* 

MINEReaponae.TimeJn.aec 

MlNE.AIarin_DurationJn_aec 

MINEMa)t_Detection_Diatance_in_ineter 

MlNE.Azimuth_Coverage_Central_AngleJn_I>eg 

MINEAzimuth_Coverage_DeltaJn_D^ 

MINEBevation_Covetage_Central^AngIeJn_Deg 

MO^Bevation_Coverage_DeltaJn.D^ 

MINEDetection_Probability_Real 

MlNEDetection_Probabili^_Falae 

MINE.Detection_Aocutacy_in_Deg 

MlNE.Ufe_Counldown_in_sec 

* 

NIS.Reaponse_Ti(ne_in_sec 

NIS.AIann_DurationJn_3ec 


1 

10 

1 


LWR 

MWS 

FASR 

MFD 

NC5 

MCD 

ROS 

CMDME 

TCS 

NBCOP 

MCO 

ROS 

CMINE 

TC3 

KBCOP 

10 


0.2 


1.2 

3.0 

6000.0 

22.5 
0.0 
ISO.O 
15.0 
25.0 
0.9S 
2.0 
30.0 

0.3 

3.0 

0.0 

180.0 

13.0 

25.0 

0.92 

0.97 

0.97 

3.0 

30.0 

0.3 

3.0 

5000.0 

0.0 

10.0 

0.0 

5.0 

0.95 

0.90 

1.0 

5.0 

60.0 

0.2 

2.0 

36.5 
0.0 
11.8 
-43.31 
1.49 
0.90 
0.10 
0.0 
30.0 

4.0 

3.0 


TRWR 


MINE 
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NIS.Aziinuth_Covtfa9t_CcntfaLAnglc_in_Deg 

NlSAiiinuth_Cov«c«gc_Delt«.ln_D^ 

NiS.EIcvatlon_Cov«tagc_C«ntral.An^e_in_Deg 

NlS.ElavMion_Cov«ngc_Dclta_in_D^ 

NlS.OMKtian_Di>iBncaLjEnBn«_Off 

Nt&DMKtian^rofaabailiaL!Engine_Off 

NSJdtntificMion_DiatanoMuE<^nc-Off 

NlS.Id«ntific>tion_PralMbiUliciLEnginc_Off 

NIS.D(lKlion_Di*i>ncci-EnBn«_On 

NlS.0iMcciiorLPiob^iliiicf_&gin«L.On 

N15Jdcniifiation_Di«t>ncH_EnBne_On 

NlS.ldcnltfic«lion_PrababUili*iuwgine_On 

NIS.DetKlicm.>ocutacy_ii!_Dcg 

NIS.Up<UMLFnqucncy_in_fcc 

NI&Uf^Coiimdownjiv_icc 

« 

IRWR-RciponicjniMLin-fcc 

TKWR.Alarin_Duiaiion_in.jcc 

TRWR.Aziinudt_Covefage_Central_Angle_in_Oeg 

TRWKAziinuth_Cavcrage_DcluJn_D^ 

TRWK.B«vation_Ccwetage_Ccntial_AngleJn_Dcg 

TRWR.BcvBtion_Coverage.'Dciu_in_D^ 

TRWR.Detectian_Probabaity 

TRWR.Detection_Accuracy_in_Oeg 

TRWKLi<c_Counldown_in_tec 

« 

MFDReiponi«_Tiinc_in_scc 

KiFO.Alann_Duralion_in_iec 

I<ffDAzi(nutti_Coveragc_Cenlral_AnglcJn_I>g 

MFD.A2iinulh_Covctagc_Delia_in_D^ 

MFD.EIevalion_Coveri4C_Central_An^e_in_Dcg 

MFD.BcvalionjCavenge_Dcita_in_0^ 

MFDLDetection_ftobabiUty 

MFO.OeMclion.Accuta^Jn_Deg 

MroUfa_G>unida%vnJn.jec 

* 

NCS.Raponac_TiinOn_aee 

N^.Alann_Duration_in_jec 

NCS.A2iinuth_Covcrage_CentraI_Angle_in_Deg 

NCSAzimuth_Coverage_Delta_in_0^ 

NCS.Bev8tioii_Coverage_Central_Angle_in_Dsg 

NCS.Bcva«ion_Covcrage_DdtaJ(v.D^ 

NCS.Detcnion_Probability 

NCS.De(cction_Aocuta(7_in_Deg 

NCS.Ufe_CountdownJn_hour 

$ 

aCounIrrmraiiires 

« 

ROS.Covctage_AngleJn_Deg 

ROSA4ax_TuRet_Roiation_Rate 

ROS.Launch_Diaiance_in_ineteT 

R05.Response_TiineJnjMC 

« 

MCDJ{ciponae_Tune_in_sec 

MCD.Jain_TiincJn.jec 

MCDAziinuth_Covetage_Central_AnglOn_Deg 

MCD.Aziinuth_Coverage_I>ita.in_D^ 

MCD.Bevation_Coverage_CeniraLAngieJn_Deg 

MCD.Beva«ion_Coverage_Del«a_in_Des 

MroA4ax_Turret_Rate 

« 

CPSRccponsc.TimeJn.jec  , 

CPS.Jam_Tnwe_in_jec 

CFSAzimuth_Coverage_Central.Angle_in_Deg 

CF5.Aziinuth_Coveiage.Delta.in_Deg 

CPS.Bevadon_Coverage_Central.Angle_in_Deg 

CPS.Bevation_Coverage_Deita_in_Deg 

CPSAlax_Turret_Rate 

« 

LCMD.Response_Tiine_in_sec 

LCMD.Jain_TiineJn_sec 

LCXD.Dea7_DistanceJn_meter 

LCMD.Max_Turret_Rate 

f 

CMINE.Responce_Tiine_in_sec 

CMINE]ain_Tiine_in_iec 

» 

NBCOP.Rasponse_Tiine_in_sec 

NBCOP.Crew_Ufe_Cbuntdown_in_sec 

NBCOP.Activation_Time_in_hour 

NBCOP.Decontamination_Probability 


0.0 

180.0 

0.0 

60.0 


5000.0 

7000.0 

10000.0 

12000.0 

15000.0 

18000.0 

1.0 

0.93 

0.90 

0.85 

0.73 

0.50 

5000.0 

7000.0 

10000.0 

1.0 

0.86 

0.66 

2000.0 

4000.0 

7000.0 

10000.0 

12000.0 

15000.0 

1.0 

0.90 

0.79 

0.71 

0.64 

0.57 

2000.0 

4000.0 

7000.0 

1.0 

0.84 

0.71 

6.0 

5.0 

60.0 


1.0 

3.0 

0.0 

120.0 

37.3 

62.5 

0.99 

10.0 

30.0 

O.S 

0.5 

0.0 

ISO.O 

IS.C 

23.0 

0.95 

2.0 

30.0 

0.3 

3.0 

0.0 

180.0 

O.P 

90.0 

0.93 

0.0 

6.0 


13.0 

43.0 

30.0 

0.0 

0.2 

3.0 

0.0 

11.0 

0.0 

5.0 

128.57 

0.5 

3.0 

0.0 

60.0 

15.0 

15.0 

128.57 

0.5 

3.0 

20.0 

360.0 

0.5 

3.0 

30.0 

60.0 

8.0 

0.98 
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« 

ATKJJtMponML.TiiM.in.MC  0.5 

A'ntUun.TiaiOn.jac  3-0 

ATR]JUiinuth_Caw«ta8(_CcninLAnglOn.Dc8  0.0 

ATIQjtJdinuth_CcRrtrigt_D(iaJn_Deg  180.0 

ATKI.E>cvMian_Cavmgc_Ctniral_Anglc_in_Deg  40.0 

ATRI.EIcvaiion_Cov«ngf_DtliaJnJD(g  50.0 

AnVAtaxJTumtJUte  128.57 

*  I 

‘iCS.Cowgt.Anglt.in.Deg  90.0 

TCSJnvtntoiy  2  2 

« 

Qiaff.RciponM_TiBieJ<i.Jcc  0.5 

OiaffJnvtMocy  30 

Chaff-DuntianJnjMC  8.0 

aufi;UancK_DiMaflA_iii_Dneter  75.0 

Qutf{.LauncK.AnglOn-Dcg  45.0 

ChaffJtadiiitJn-iMie  21.0 

ChiiffA4ax_TuR«t_Katc  128.57 

« 

FUr«iJbiponic_rune_in_iK  0.5 

Flarw-Invimofy  30 

FUict-DuniionJnjHc  4.0 

FUrctLauiich_Dttancc_i>i-(neier  130.0 

Flarc*.LMUich_AnglcJn_Deg  43.0 

Flarci.IUdius_in_incte  22.0 

FUKt.Max_Tunet_Katc  128.37 

« 

CFIRRMax_Turrct_Rate  43.0 

« 

TSCANA<*x_Tutr«_Rate  3.0 

« 

Dtta_CotteciionJPraj_Period_in_scc  30.0 

f 


*  Th«  following  defines  the  grenade  toad  for  the  tunet  sectofs 

*  starting  from  the  gun  (top)  and  going  dodnvise  in  15  degree  inaements. 
t  Label  tab  LSAl  tab  M76  tab  lAiSl ,  top  and  clockwise 

Sector.O  2  2  0 

Sector.lS  2  2  0 

Sector_30  2  2  0 

Sector.4S  1  1  0 

Sector.60  1  1  0 

Sector^  1  1  0 

Sector_90  1  1  0 

Sector.lOS  2  2  0 

Sectar.120  2  2  0 

Sacior_133  110 

Sector_150  1  1  0 

Sector_165  1  1  0 

Sectbr_180  1  1  0 

Sectot_19S  110 

Sector_210  1  1  0 

Sector_225  1  1  0 

Sector_240  1  1  0 

Sector_253  2  2  0 

Sector_270  2  2  0 

SeciotJ85  1  1  0 

Sector_300  1  1  0 

Sectot_315  110 

Sector_330  1  1  0 

Sector^  2  2  0 

« 

(  The  foltowing  is  the  CM  Thnat  Mapping  to  be  used  by  VIDS. 

*  Valid  Order  values:  0-8.  The  0  order  is  the  first  CM  to  be  used. 

* 


2 


2 


•threat  dass 

priority 

list  of  04s  in  priority  selection  order 

Class_l 

14 

CPS 

MCD 

VIS 

4 

IR 

4 

Class_2 

13 

CPS 

MCD 

VIS 

4 

IR 

4 

Class_3 

10 

CPS 

MCD 

VIS 

4 

IR 

4 

Class_4 

6 

CPS 

ICMD 

IR 

4 

VIS 

4 

Class_5 

8 

CPS 

IR 

» 

VIS 

4 

Class_6 

11 

CPS 

MCD 

\TS 

4 

IR 

4 

Class.? 

7 

CPS 

IR 

4 

VIS 

4 

Class_8 

12 

CPS 

MCD 

VIS 

4 

IR 

4 

Class.9 

9 

CPS 

MCD 

IR 

4 

VIS 

4 

Class.lO 

5 

CPS 

VIS 

4 

IR 

4 

Qassjdine 

1 

CMINE 

Gass.Chemical 

2 

NBCOP 

Qass3Iuzxle 

IS 

CPS 

VIS 

4 

IR 

4 

Qass^^uzale.w.LRF 

4 

CPS 

VIS 

4 

IR 

4 

Oaas_Mui2le_w_TCS 

3 

CPS 

VIS 

4 

IR 

4 

Flares 

Flares 
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ClMi_H*iiGO(>ter 

QaM.Tuik 

ClanJntentry_Support 
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15 

16 
17 


¥ 

I 
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